feat(blaze): prune checkpoint history - #2474

Why

Blaze can commit and list checkpoints but has no way to reclaim the disk
space held by checkpoints that neither the current HEAD nor any explicitly
protected identifier can still reach. Operators need a bounded, restart-safe
way to remove unreachable checkpoint history without touching the active
capture chain.

What changed

• Add POST /v1/sandboxes/{id}/checkpoints/prune. The request body is
  optional; when present it must be a JSON object with only a protected
  array of canonical ckpt-<uuid> identifiers. The response reports the
  removed count and identifiers.
• Prune protects the current HEAD together with its full parent chain and the
  ancestor chains of every explicitly protected identifier. Unknown protected
  identifiers are rejected with HTTP 400 before any deletion; the endpoint
  otherwise returns HTTP 200 with the removed list (which may be empty).
• Publish a named tombstone directory before renaming a candidate. The paired
  owner file records the sandbox, checkpoint, nonce, and directory identity
  so restart cleanup can identify each pruned candidate and finish removing
  it. renameat NOREPLACE prevents silently overwriting a concurrent
  candidate; identity revalidation between planning and rename rejects a
  catalog that has changed since the plan was built.
• Extend classify_scratch_name to recognize .prune.<checkpoint>.<nonce>
  tombstone directories and their .owner files. remove_sandbox and the
  existing scratch cleanup already act on these categories, so restart
  cleanup or destroy removes any interrupted prune leftovers.
• Serialize with capture and list through the existing per-sandbox operation
  lock and run the actual scan on the blocking pool.
• Document the route, protection rules, response shape, tombstone flow, and
  restart behavior in the English and Chinese README and runtime user guide.

No /v1/instances compatibility route is added. No dependency on #2473,
#2475, or #2471.

Related issue

Follow-up on #2472 (capture and list). Delivers the pruning entry point that
was intentionally deferred.

User / Agent impact

Operators and agents can reclaim disk space held by unreachable checkpoint
branches without stopping or destroying the sandbox. The endpoint acquires
the same per-sandbox operation lock as capture and list, so callers do not
observe partial history changes.

Risk and compatibility

• Public CLI, API, configuration, or documented behavior changed
• Privileged or security-sensitive behavior changed
• Cross-component contract changed
• Migration or rollback guidance is needed

This adds one HTTP endpoint and two new scratch-name categories inside the
sandbox checkpoint namespace. Existing catalogs remain compatible: no new
files appear until an operator calls prune, and any interrupted prune leaves
only well-formed tombstone and owner files that the existing catalog
cleanup already handles.

Prune never touches the HEAD-reachable chain, so a caller with the wrong
protected list will at worst leave more history than intended; a repeat
call with an updated list is safe. The endpoint fails closed before deletion
on any protected identifier that is not currently committed.

Validation

Exact candidate:

• base: 7a8005874e078455e9acde0f4f6981839919489d (main, includes merged feat(blaze): capture sandbox checkpoints #2472)
• commit: 9fcfb424fbdca747aec439a928c2c835547597a5
• tree: e5f2bc3aa30aa7ee998ebb308d5c0cb7798a9ff9

An uninterrupted Linux x86_64 run on Rust 1.88.0 completed for the tree above.
It used a fresh source directory, a dedicated Cargo home, and an initially
empty task-exclusive target directory for each stage. Every Cargo stage ran
with --locked --offline.

Focused prune coverage:

• checkpoint_store::tests::prune_preserves_head_and_explicit_lineages proves
  the HEAD chain and every ancestor of a protected identifier survive while an
  unreachable branch is removed.
• checkpoint_store::tests::prune_rejects_a_protected_id_that_is_not_committed
  proves an unknown protected identifier is rejected before deletion.
• checkpoint_store::tests::prune_leaves_a_missing_sandbox_directory_untouched
  proves a sandbox without any checkpoint namespace remains untouched.
• checkpoint_store::tests::prune_removes_owner_and_tombstone_after_completion
  proves the sandbox directory contains no prune scratch after a successful
  prune.
• api::tests::prune_route_reports_no_removals_when_history_is_all_reachable
  proves the HTTP contract for a fully-reachable history.
• api::tests::prune_route_rejects_unknown_body_fields proves the request
  body accepts only protected.
• api::tests::prune_route_rejects_unknown_protected_checkpoint_as_bad_request
  proves a canonical but uncommitted protected identifier answers HTTP 400.
• checkpoint_store::tests::prune_reports_partial_cleanup_when_post_tombstone_work_fails
  proves a failure after the tombstone rename returns PruneOutcome::PartialCleanup
  with the confirmed removed prefix, retains the prune scratch for later
  cleanup, and leaves the HEAD chain intact.
• api::tests::prune_route_rejects_a_recovery_required_sandbox proves a
  recovery-required sandbox answers HTTP 409 instead of silently accepting a
  prune retry that would bypass retained scratch.

Documentation and rollback

The English and Chinese Blaze README and runtime user guide document the new
endpoint, protection rules, response shape, tombstone flow, and restart
behavior. No changelog entry is added because Blaze has not been released.

To roll back, stop the Blaze daemon and confirm that no sandbox has active
prune scratch (files starting with .prune. inside a sandbox checkpoint
directory). Revert this commit together with its API, checkpoint-store, and
documentation changes. Any tombstone or owner files left on disk are safe to
delete by hand once the daemon is stopped; the file provider will not
reference them after revert.